@zeebo could you take a look?

Hmm.. I think this changes some semantics. Specifically, a MsgRecv returning an io.EOF indicates that the other end has cleanly closed the stream. That is now happening even in the case of a "hard close" of the underlying transport. That's why the manager was ignoring the error and terminating the stream with context.Canceled. The test as written was to enforce that property, actually.

Is there another way we should surface this error?

Because this error wasn't being surfaced, it was very difficult for us to log the true reason a stream was being terminated.

Perhaps the manager code can check to see if the error was io.EOF and terminate with context.Canceled, and otherwise terminate with the provided error. I think that would be fine to both surface unexpected transport errors as well as maintain the property that clean, intentional closes can be detected.

Or, maybe we do something like io.ReadFull and change io.EOF into io.ErrUnexpectedEOF instead of the previously suggested context.Canceled. I think that's better.

This pull request has been mentioned on Storj Community Forum (official). There might be relevant details there:

https://forum.storj.io/t/introducing-drpc-our-replacement-for-grpc/13486/13